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T.OGICIEL DE GENERATION DE CODE D> APPLICATION 
TNFORMATIOUE ET LANGAGE DE DESCRIPTION PE LOGICIEL 



5 DQMAINE TECHNIQUE 

La pr6sente iavCTition conceme \m Idgiciel de gSneration du code infonnatique 
d*au moins ime partie d'lme application infonnatique informatique k partir d^une 
description de ladite partie de Tapplication informatique. L*invention conceme aussi 
un langage de description de logiciel, notanunent du type langage objet de 
1 0 mod61isation d' application informatique. 

Dans la presente description, nous employons les termes suivants avec le sens 
indiqu6 : 

- « application informatique » : d6signe tout programme ou tout ensemble de 
programmes pr6vus pour fonctionner conjointement, dont le but est de rendre des 

15 services a leurs utilisateurs ; une application est constitu6e de : 

- ses interfaces, c*est-a-dire, Tinteraction avec le monde ext6rieur k 
Tapplication (utilisateurs humains, autres syst^es d^information), 

- de ses traitements, c'est-i-dire ses rouages internes, ses algorithmes, 

- et de ses doimtes, c'est-i-dire de toutes ses structures d'information 
20 stock^es en m6moire vive ou sxir support persistant, comme un disque 

dur. 

- « architecture technique » : il s'agit de Tensemble des technologies utilisees pour 

r6aliser une application Siformatique, ainsi que des regies de repartition 
permettant d'affecter les difF6rents parties de cette application sur ces difiKrentes 
25 technologies et des modes de communications entre ces technologies. 

- « classe » : d6signe la notion de classe commun6ment manipul6e dans les 
formalisme de mod61isation et langages de programmation orient6 objet c'est-i- 
dire 1' agr6gation de donn6es et de traitements (appel6s respectivement attributs et 
m6thodes) destin6 k fonctionner ensemble dans une application informatique, 

30 - « client » : d6signe Tutilisateur de services qu*il ne d6finit pas lui m&me. Un client 
utilise les services mis a disposition par des serveurs. Par extension, on parle 
d'applications client, d*interface client, etc. 

- « code source » : texte ecrit dans un langage de programmation ou de description 

qui est ensuite compile en langage machine afin d'&tre execut6 par une plate- 
35 forme informatique mat6rielle, ou int^r6t6 par un environnement logiciel ou 
mat6riel d' interpretation. 

- « code compile » : resultat de reparation de compilation d*un code source. 

- « code » : designe indifferenunent du code source ou du code compil6. 



Ri\Bf0VCte\l«O(M9299BP SERB doc - 1/33 



30Ar7ya2. 18.05 




- « compilation » : action de traduction d*une description exprim6e dans un langage 

de progranunadon vers le langage natif d'une plate-forme informatique mat6rielle, 
avant son execution par cette plate-forme informatique mat6rielle. 

- « serveur » : d6signe le foumisseur d'un service. Les services mis k disposition par 
5 un serveur peuvent Stre utilis6s par des clients. Par extension, on parle 

d' ^plications serveur, d'interface serveur, etc. 

- « heritage »: relation attachant deux classes dont une premi&re h6rite d'une 
seconde et permettant k la premise d*enrichir la definition de la seconde tout en 
conservant toutes les caract6ristiques de cette seconde classe. 

10 - « interface » : dans une application informatique, une interface est mi ensemble de 
points d'6change qui pennettent a Tapplication de communiquer avec le monde 
exteriem- (par exemple, d'autres applications ou des utilisateurs), et de lui 
presenter des services et des informations. 

- « IHM » : signifie Interface Homme Machine, et est synonyme d'interface 
15 utilisateur. 

- « interface utilisateur » : dans une application informatique, Tinterface utilisateur 

est ime interface particuliere : c'est la partie d*une application d6di6e 
specifiquement k la communication k double sens entre cette application et ses 
utilisateurs. Ainsi, grSce k riHM, I'application pr6sente les dorm6es et 

20 informations traitees, par exemple en les afBlchant graphiquement sur Tecran, et 
I'utilisateur saisit des donn6es et d6clenche des actions; par temple gr&ce k des 
: champs de formulaire, des boutons et des menus, au moyen du clavier et de la 
souris. Ces IHM sont constitutes de composants imitant graphiquement 
Tapparence d*objets du monde reel qui permettent de recoimaJtre les fonctions 

25 affich6es correspondantes. Par exemple, les doimees sont souvent affichees et 
modifiables dans mi rectangle trac6 a rdcran, imitant les champs de formulaire 
papier, de mSme les actions sont figurees par mi texte dans une boite rectangulaire 
en relief s'enfon9ant quand on clique dessus, a Tinstar des boutons des appareils 
61ectriques. L*IHM est constitute d'mie partie statique et d'mie partie dynamique. 
- 30 . La partie statique comprend tons les aspects graphiques que sont la mise.en forme 
et la pr6sentation de Tinformation. La partie dynamique quant k elle comprend 
tous ce qui permet k Tutilisateur. de commander Tapplication et d'interagir avec 
elle, tels que les $v6nements issus de periphtriques et la gestion de la navigation. 

- « Interprdtation » : action de traduction d'mie description exprimte dans un langage 
35 de programmation vers le langage natif d'mi ordinateur pendant son execution par 

I'ordinatexir. 

- « langage de progranunation » : formalisme permettant de dtcrire des actions 
destinees k Stre ex6cutees par un ordinatem:. Ces descriptions sont soit execut6es 
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directement par rordinateur, lorsque le foixnalisme tiatif de rordinateur est utilis6, 
soit aprte compilation pu inteipr6tation. Une application infoimatique est dScrite 
en utilisant un ou plusiexjrs langages de programmation. - «modelisation»: 
designe Taction de produire ime description d'un objet a r6aliser, afin de servir de 

5 modele a sa rdalisation effective. Cette action de mod61isation consiste souvent, 
en infotmatique, a s'abstraire de certaines considerations propres k la realisation, 
telles que les technologies employees, les considerations techniques, et les 
langages de programmation utilises. Cela permet de simplifier le travail de 
conception en r6duisant le nombre de concepts k manipuler. 

10 - « modelisation abstraite » : est Tacte de rqjresenter les applications informatiques a 
realiser dans un formalisme ind6pendant des technologies et des considerations 
techniques en se basant sur des concepts abstraits. 

- «outil de d6veloppement logiciel»: application informatique pennettaint de 
construire des applications infomiatiques. 

15 - « technologie » : element logiciel pouvant @tre un composant d'une application 
informatique rSalisee ou bien un el6ment intermediaire de son processus de 
realisation comme par exemple im outil ou un langage de programmation. On 
regroupe sous ce terme entre autres k la fois les langages de programmation, les . 
ateliers de d6veloppement logiciels qui y sont associds, les con^qposants logiciels 

20 qu'on pent assembler dans une application, les services et ressources techniques 
mis a disposition par un environnement mat6riel ou logiciel et les protocoles de 
communication entre 616ments logiciels. 

- « g6n6ration de code » : designe la production automatique de code pour une 

application informatique au moyen d'un g6n6rateur. Elie se fait k partir d'une 
25 description d'application logicielle foumie au g6nerateur et servant k piloter cette 
generation. Celui-ci, apr^s analyse de cette description, construit le code attendu 
en sortie. Cette description peut-Stre exprimee dans un langage de plus haut 
niveau que celui dans lequel le code sera produit Ainsi on fait souvent le choix 
d'un langage le plus proche possible de Texpression naturelle humaine soit sous 
30 forme graphique soit sous forme textuelle. Ainsi on pent exploiter le generateur 
sans avoir k connaftre le formalisme du langage de programmation utilise dans le 
code genere. 

Par le tenne« langage », on entend tons les fomiats de representations 
permettant de decrire tout ou partie des logiciels afin de contribuer directement ou 
35 indirectement k leur construction effective. 
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TECHNIQUE ANTERIEURE 

ActuellemOTt, les outils qui permettent de gen&rer du code n*oflB:ent cette 
possibilit6 que pour un seul langage de programmation a la fois ou un ensemble de 
langage k la structure et aux roles preddfinis et jag6s. Cette limite vient du fait que le 
5 g6n6rateur de code est li6 explicitement dans sa structure m§me h ce langage ou i cet 
ensemble de langages. Ainsi, lorsque Ton souhaite produire automatiquem^t du 
code pour une architecture technique quelconque comprenant plusieurs langages de 
programmation, on est g6n6ralement oblig6 de foumir plusieurs descriptions en 
entr6e de plusieurs generateiirs de code. Cela revient a effectuer manuellement la 

10 repartition du code sur les technologies de Tarchitecture technique. Ce cas se 
pr6sOTte lorsque Tarchitecture technique de TappUcation i r6aliser . comporte 
plusieurs technologies. Et c'est aujourd'hui le cas le plus frequent dans le cadre du 
d6veloppement d'une application informatique. 

Pour efifectuer une g6neration de code, les g6n6rateurs de code existant se 

15 fondent sur des descriptions de plus haut niveau que le niveau du code h produire. 
Elles reposent souvent sur des langages de modelisation comme UML et d'en 
g6nerer le code dans un language de progranmsiation donn6 

A titre d'exemple, I'outil Rational Rose® de la societe Rational est un des 
outils permettant de r6aliser une mod61isation abstraite d'une application 

20 informatique en utilisant UML. 

En ce qui conceme les languages, on pent les categoriser sur un diagramme k 
deux dimensions comme illustr6 sur la figure 1. La premiere, Techelle verticale, 
repr6sente le caractfere d*ind6pendance technologique du langage, EUe crolt k mesure 
que les informations decrites grSce au langage imposent de moins en moins, du fait 

25 de leur forme, d'utiliser telle ou telle plate-forme technique ou fonctionnelle. La 
seconde, Ttehelle horizontale, repr&ente la facility qu'il y a identifier 
automatiquement le role, la structure et le fonctionnement d'une application a partir 
de sa description faite dans un langage, c'est-4-dire la facilite d'analyse s6mantique 
automatique de Tapplication a partir de sa description. Dit encore autrement, il s'agit 

.30 ....fie.l^ fswJilite a cojavertir cette description dans ime forme directement lisible par 
rhomme, precisant le fonctionnement et le sens de cette application- Cette 6chelle 
crolt k mesure qa^k la fois les langages : 

- offrent des notions de plus en plus nombreuses et riches avec lesquelles on 
pent d6crire im service technique ou fonctiomiel domie de plus en plus 

35 riche en utilisant un nombre de ces notions de plus en plus faible, 

- imposent au programmeur Tutilisation de plus en plus exclusive de ces 
notions pour realiser cette description. 

On pent distinguer les differents types de langages sxiivants : 
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- les lang^es de 16re g&ieration : langages machines (par exemple : code 
binaire x86 on 68000) ; > 

- les langages de 2&me generation : langages symboliques (par exemple : 
assembleur x86 ou 68000) ; 

5 - les langages de 3^e generation : langages proceduraux et langages objets 

(par exemple : Basic ou Java) ; 

- les langages de 4dme generation: langages manipulant des notions 
agreg6es et classiquraaent pris en charge par des ateliers de genie logiciel 
dedies (par exemple : PowerBviilder ou Windev) ; 

10 - les langages de modelisation abstraite (par exemple : UML ou Merise) ; 

- les langages de description (par exemple : HTML, WML). 

Les langages de premiere generation sont les langages de plus bas niveau. Les 
instructions qui les composent sont directement comprehensibles par un processeur. 
Elles sont eiementaires et en nombre restreint En pratique, elles consistent en des 

15 nombres (exprim6s en binaire) codifiant les actions realisables par le processeur en 
intmie ou bien en interaction avec son enviroimement materiel. Ces langages sont 
intimement lies a renvironnement materiel capable de les executer, Cette 
dependance technologique les place tout en bas de rechelle de dependance 
technologique. En ce qui conc^ne I'analyse semantique automatique, celle-ci est 

20 pratiquement impossible du fait du caractere eiementaire des instructions 
disponibles. En effet, la moindre operation k laquelle un humain pourrait donner une 
unite de sens pent necessiter plusieurs centaines d'instructions exprim^es en langage 
machine. Ceci justifie le placement de ces langages tout en bas de Techelle de facilite 
d*analyse semantique. 

25 Les langages de deuxieme gen6ration sont apparus pour permettre aux 

programmeurs de ne plus utiliser directement les codes binaires des langages 
machmes. En lieu et place de ces codes, les programmeurs ont pu utiliser des 
symboles plus directement comprehensibles par rhomme. Neanmoins, ces langages 
symboliques restent des langages d'aussi bas niveau que les langages de premiere 

30 generation, et seule la designation des operations eiementaires du langages change de 
forme (passant du binaire k une description alphanumerique). En ejBFet, leur 
formalisme est en bijection directe avec les codes binaires des langages de premiere 
generation. Us sont done, comme ces demiers, plac6s tout en bas de rechelle 
d'independance technologique. En ce qui conceme I'analyse semantique 

35 automatique, celle-ci est pratiquement impossible sans disposer d'un analysein: d'une 
intelligence au moins egale k celle du programmeur ayant realise la description de 
cette application dans ce langage. En effet, le formalisme est de si bas niveau que les 
seuls elements qui pourraient porter une information de sens fonctionnel ou 
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technique pouiraient etre inclus dans les commentaires. Or le formaiisme n*offre 
aucun cadre fonctionnel ou technique structure, ce qui interdit de les exploiter pour 
toute analyse dSterministe. 

Les langages de troisieme g^tieration sent ^parus pour permettre de ddcrire 
5 une application informatique ind^endanmient du materiel qui exploitera cette 
description pour ex6cuter Ts^jplication en question et pour donner accds k des 
op6rations de base plus complexes que celles des langages de premifere et deuxieme 
gen6ration. Neanmoins, meme si le formaiisme et la syntaxe sont abstraits du 
materiel, les possibilites de description qu'offirent ces langages sont intimement li6es 

10 a renvironnement technique qui sera utilise pour ex6cuter la description effectu6e. 
. . Ces langages constituent done un premier progr^ d'indep^dance technologique qui 
permet an programmeur d'ignorer la manifere dont les fonctions de bases foumies par 
le langage sont mise en oeuvre snr la plate-forme technique cible, mais cela ne 
dispense pas le progranuneur de devoir agencer ces fonctions de base d'une certaine 

15 manifere afin de prendre en compte les sp^cificites de cette plate-forme. En ce qui 
conceme la facilite d*analyse s6mantique automatique, les langages de troisieme 
g6n6ration constituent egalement un progrds car ils ojB&ent un cadre structur6 pour 
certains services techniques ou fonctionnels notamment sur la structure des routines 
algorithmiques et sur la stmcture des donn^es manipulees. N6anmoins, ils offrent 

20 souvent la possibilit6 de s'extraire ou de contoumer le cadre quails foumissent pour 
d6crire un service donn6. Cependant, ce niveau d'analyse ne pent depasser le niveau 
de complexity des fonctions de bases foumies par le langage, et il est d6grad6 par 
cette possibility de contoumement, Ainsi, pour constituer des unites de sens 
permettant d'interpreter le fonctionnement de Tapplication d6crite, il faut 

25 ^intervention d'un hxmiain ou un outil d'analyse fonde sur I'intelligence artificielle 
qui d6passe ce que Ton sait faire aujourd'hui. 

Les langages de quatrifeme g&ieration (L4G) sont couples a des outils 
commun6ment appeles AGL (Atelier de G6nie Logiciel). Ce maiiage est si fort qu'on 
a coutume d'employer indifferCTunent I'un ou Tautre des deux termes L4G ou AGL. 

30_ lis, spnt ..ne.s..dlune .envie de .capitalisation conceipant-la cr6ation de composants. - 
techniques. Ces AGL, partant du principe que la plupart des applications peuvent Stre 
construites par assemblage et param6trage de composants g6n6riques, proposent une 
large palette de composants pred6finis qu'il suffit de param6trer et de faire 
communiquer entre eux, Ces AGL sont tous li6s k un langage technique sp6cifique 

35 qui, comme les langages de troisieme g6n6ration, oflfre des possibilitfe limit6es par 
renvironnement technologique d*ex6cution duquel ils dependent. Cette limite place 
ces L4G au m8me niveau d'independance technologique que les langages de 
troisifeme gen6ration. Par centre, en ce qui conceme la facility d'analyse s6mantique 
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automatique, celle-ci est superieure k tous ceux cit6s prec6depameiit. En eflFet, ies 
AGL imposeat strictement au progranuneur la structure permettant de d6crire un 
service technique ou fonctionnel. L*analyse s6mantique automatique peut done se 
reposer sur un d6tennimsme parfait pour d6celer ces services, avec la limite que le 
5 service identifi6 est associ6 k une realisation spScifique a une platefonne technique 
unique, et n'est pas un service gdnSrique. Cette analyse ne peut done pas toujours 
prSsunoier de Tintention fonctioimelle du progranuneur, mais elle peut toujours 
determiner son intention technique. 

Les langages de modelisation abstraite sent nes d'une envie de description des 
10 applications independante de tout caract^re technologique. Us se sont concentres sur 
les aspects algorithmiques et de structure des donnees. lis sont utilises pour 
d6velopper des applications en deux phases : la premiere conceme la creation d'un 
modele et la seconde la generation automatique du code dans im langage (la plupart 
du temps un langage de troisifeme generation). Cette capacite de creer un modele 
15 independant des technologies pour la plupart des services a d6crire dans une 
application informatique nous fait le placer au dessus des autres langages que nous 
avons cit6s jusqu'i present sur rechelle de Tind^endance technologique. 
Cependant, pour pouvoir g6n6rer une application complete, il est indispensable, . 
lorsqu'on utilise ces outils, d^inclure dans le module des liens avec les elements de 
20 base du langage de troisieme generation qui sera finalement utilise, ce qiii rend in . 
fine le modeie dependant de cette technologic. Enfin, il est n6cessaire de decrire 
I'application informatique qu*on modeiise d*une fa9on particuliere selon la 
configuration de T architecture technique, ce qui rend le modele dependant de celle- 
ci. En ce qui conceme la facilite d'analyse semantique automatique, celle-ci est 
25 equivalente k celle obtenue par Tutilisation d'un langage de troisieme generation car 
les langages de modelisation abstraite of&ent un cadre structure pour decrire certains 
services fonctionnels. L' analyse semantique automatique des modules reste ainsi, du 
fait de la majoipulation de notions de has niveau et tres abstraites (classe, relation, 
methode, collaboration,...)* incapable d*identifier automatiquement des services 
30 complsKes techniques ou fonctionnels particuli^s, sans intervention humaine ou sans 
module d'intelligence artificiel depassant retat de Tart actuel. 

Les langages de description sont fondes sur une syntaxe deSnissant de maniere 
figee les elements informatiques qu^on peut decrire ea les utilisant. Comme les 
langages de 4eme g^eration, ils definissent des notions de plus haut niveau qui sont 
35 destinees k Stre assembiees pour former une description. Le sujet de cette description 
est souvent graphique et est notamment utilise en informatique pour decrire une 
interface homme machine. Historiquement, ils servaient a mettre en forme du texte, 
avant impression ou af&chage k recran. Les elements qu'ils permettent de decrire 
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sont statiques. Pour introduire du dynamisme, ces langages sont parfois associ6s i un 
langage de troisi^e g6a6ration. Us ne sont pas destinSs k peimettre la production 
d'une application. Leur prise en charge repose sur un outil appel6 navigateurs, qui les 
interprete pour effectuer, ce qu'on appelle le rendu de leur description, c'est-Ji-dire la 

5 transformation de Tinformation contenue dans le langage de description ainsi que ce 
dernier le pr6voit d*2q>res sa sp6cification. Concemant Tind^endance technologique, 
ils permettent dans le cadre des capacity du langage de faire afiBcher leur description 
sur n'importe quelle plate-forme materielle et logicielle, mais ils imposent une 
architecture technique particuliere, basee sm Texistence d*un outil de rendu. Par 

10 contra, en ce qui conceme la facilite d*analyse semantique automatique, elle est au 
• • niveau de celle des L4G, car elle est fondle, comme eux sur une structure 
contraignante de services predefinis, mais imposant une mise en oeuvre technique 
particuliere. 

15 EXPOSE DE L'INVENTION 

L'invention vise k faciliter le d6veloppement des applications informatiques et 
de permettre ce d6veloppement de fa9on plus rapide en comparaison de Tart 
anterieur. Elle vise aussi k rendre plus fiable k la fois ^application informatique 
d6velopp6e et le d6roulement du d6veloppement de 1' application informatique. Elle 

20 vise encore a faciliter la r6utilisation des d6veloppements r6alis6es pour une 
application informatique par exemple pour le d6veloppement d'une autre application 
ou encore pour adapter Tapplication informatique k une nouvelle architecture 
technique. 

A cette fin, la pr6sente invention propose un logiciel de generation du code 
25 informatique d'au moins une partie d'une application informatique, dans lequel le 
logiciel g^nere ledit code informatique k partir d'une description de ladite partie de 
Tapplication informatique en r6partissant ladite description entre plusieurs 
g6n6rateurs de code en fonction de regies de repartition modifiables, chaque 
g6n6rateur de code traduisant la partie de ladite description qui lui est foumie, pour 
. .. .30 ..foumir au moins. une partie dudit code informatique dans un langage respectif. Ainsi, 
les regies de repartition peuvent avantageusement correspoudre k T architecture 
technique qui mettra en oeuvre T application informatique. Bien entmdu, il est 
parfaitement envisageable d'adresser ime meme partie de la description k plusieurs 
gen6rateurs de code different, par exemple si Ton souhaite g6n6rer simultan6ment le 
35 code informatique de Tapplication informatique pour plusieurs architectures 
techniques diff6retttes. Les revendications 2 a 9 definissent des modes de realisation 
preferes du logiciel selon Tinvention. Selon un austre aspect, Tinvention propose 
aussi un langage de description de logiciel, notamment du type langage objet de 
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mod^Usation d' application infoimatique, tel que d6fim dans la revendication 9. Selon 
encore un autre aspect, Tinvention propose un logiciel permettant de construire 
graphiqu^ent ou textuellement un module d' application informatique, notannnent 
un module d^interface homme-machine d* application informatique et de foumir une 
5 description du module dans le langage de description de logiciel selon Tinvention. 

D*autres caract^stiques et avantages de Tinvention apparaftront k la lecture de 
la description qui suit d'un mode de r6alisation pr6f6r6 de I'invention, donn6e h titre 
d'exemple et en r6f6rCTce au dessin annex& 

10 DESCRIFnON SOMMAIRE DBS DESSINS 

La figure I illustre schematiquement la position du language selon Tinvention 
par rapport a Tart ant6rie\ir en terme de richesse de description et de facilite 
d'analyse semantique automatique d'une part> et en terme d'ind6pendance 
technologique. 

15 . La figure 2 illustre un exemple gen6rique d'architecture technique. 

La figure 3 illustre im exemple de firagment d' architecture technique reelle 
pouvant servir k r6aliser une explication intranet HTML / JSP. 

La figure 4 est un sch6ma illustrant le fonctionnement d'un g6n6rateur de code 
architectural selon Tinvention. 
20 MANIERES PREFBREES DE REALISBR L^INVElSrnON 

Nous decrirons d'abord la mani^ pr6f6r6e de r6aliser le logiciel de g6neration , 
de code selon Tinvention avant de d6crire celle du language de description de - 
logiciel. 

25 n Le logiciel de g6n6ration de code 

Par commodite, nous designerons par la suite le logiciel de generation de code 
selon rinvention par g6n6rateur de code architectural. En effet, nous parlerons dans 
la suite de generation de code architecturale, car il s'agit de g6n6rer du code pour une 
architecture technique dans son ensemble, c'est-i-dire de repartir le code produit sur 

30 plusieurs technologies grace k des gen6rateurs de code chacun responsable d*une 
technologie de V architecture. 

La g6n6ration de code architecturale est r6alis6e par le g6n6rateur de code 
architectural qui permet automatiquement d'analyser une description d'application 
informatique, puis de r6partir automatiquement ses 616ments constitutife, afin d'en 

35 generer le code, en fonction de la description d*une architecture technique qui d6finit 
les choix k effectuer pour obtenir cette repartition sur diff6rents g6n6rateurs de code 
et adaptateurs d'interface entre technologies, chacun prenaut en charge une 
technologie particuliere. 
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Le g^6rateur de code architectural comprend les modules suivants : 

- un analyseur de description d'application capable d' analyser des flchiers de 
description d'applications logicielles exprim6s dans un format de description 
d'application, 

5 - un analyseur de description d'architecturec^able d'analyser des fichiers de 

description d' architecture technique dans un format de description d'architecture» 

- un filtre d'espace technologique, 

- des g6n6rateurs de code, 

- des adaptateurs serveur, 
10 - des ad^tateurs client, 

- un comparateur, 

- un r6partiteur, 
un coordinateur. 

Nous aliens d6crire successivement chacun de ces elements ainsi que le 
1 5 fonctionnement du g6n6rateur de code, architectural. 

l.V) Format de description d'application 

Ce fomiat est choisi pour permettre de d6crire les constituants de Tapplication 
informatiquedont on cherche k produire le code grace au g6n6rateur de code 
20 architectural. 

II pent avantageusement s'agir du language de description de logiciel selon 
rinvention plus particuli^rement dScrit au point 2). N^anmoins, d'autres formats 
peuvent fetre utilis6s. 

25 1,2) Analyseur de description d' application 

L' analyseur de description d' application est pr6vu pour traiter des fichiers de 
description d*applications logicielles exprimds dans le format d6fini au point 1.1). U 
verifie que les fichiers qu'on lui transmet sont conformes k ce format et, k defaut, il 
6met une erreur. 

30 . .. n -identifie-, sans perte d'informations n6cessaires k la realisation de 
TappUcation, les 6I6ments, 6numeres ci-dessous, k partir de ces fichiers puis les en 
extraire. Ces 616ments constituent alors une representation d6composee de la 
description de Tapplication destin6e k Stre transmise k d'autres modules. Si le format 
de description d'application le n6cessite, il pent 6tre fait appel k des fichiers extemes 

35 tels que des bibliothfeques pour completer cette analyse. Une description 
d* application effectu6e en Java par exemple, utilise des classes du langage dont la 
definition ne fait pas partie de la description d'application mais se trouve dans des 
bibliothfeques ext^es. Ces bibUoth^ues sont alors utilis6es k Tanalyseur de 
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description d' application pour reperer que la classe qu*il est en train d' analyser est 
une classe du langage. 

Les 616m6nts en question sont : 

- une liste de classes dont chacune contient, le cas Scheant, la liste de ses 
attributs typ6s et la liste de ses methods ainsi que leur signature typ6e totaaMfirat 
d6finie et le cas ech^ant, leur definition sous la forme de la s6qurace de commandes 
et operations qu'elle execute. On peut 6ventuellement y ajouter des liens vers 
d'autres classes dont la classe consid6ree ti6rite, si cette notion d'h^ritage est 
introduite. 

- la liste des dependances entre classes, mises en relation precisement avec le 
point de chaque classe on ces dependances trouvent leur origine et leur cible. Chaque 
dependance repr6sente un lien de dependance entre deux classes differentes. Dans 
cette dependance, on considfere que la classe qui est dependante de Tautre est la 
classe client. La classe dont la classe client est dependante est la classe serveur. 

La decomposition de la description de Tapplication issue de Textraction de ces 
elements est exprimee dans un format interne au g6nerateur de code architectural. Ce 
format est partag6 par tous les modules qui en ont besoin. 

1.3^ Format de description d' architecture 

Ce format est pr6vu pour decrire Tarchitecture technique sur laquelle sera 
rSparti le code produit. Ce format permet de definir : 

- des espaces technologiques : il s'agit d' ensembles, munis chacun d*im 
identifiant, constitues du regroupement des el6ments suivants : 

- de la reference a un gen6rateur de code (par son identifiant unique), ce 
gen6rateur supportant une technologic donnee qui produira le code de 
r application pour cet espace technologique, 

- d'un jeu de parametre de fonctionnement, c'est-i-dire \uie liste de 
valeurs servant a param6trer le fonctionnement de ce g6n6rateur de code 
(tel que ddfini au point 1 .6), 

- et d'un jeu de paramfetres de filtrage, c'est-Ji-dire une liste de valeurs 
destin6s au filtre d'espaces technologiques (d6fini au 1,5) afin de 
permettre k ce dernier de v6rifier si une classe (au sens du point 1 .2) est 
censee ou non etre prise en charge (au sens du 1.10) par cet espace 
technologique. 

- ses associations entre des adaptateurs et des dependances orientees entre 
espaces technologiques : pour chaque d6pendance orient6e d'un espace 
technologique envers tm autre espace technologique, on affecte un adaptateur serveur 
et im adaptateur client. La d6pendauce est orient6e selon le sens defini par les rdles 
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dans cette dependance allant de .respace qui est dependant vers Tespace dont il 
depend. Dans cette orientation, on consid&re que Tespace qui est d6pradant est 
Tespace client et que Tespace dont il depend est Tespace serveur. 

Le schfetna de la figure 2 illustre un exemple g6n6rique d'architecture 
5 technique* 

Le schema ci-dessus montre 3 espaces technologiques (El) ^2) et (B3) dans 
lequel : 

- respace (El) est pris en charge par le gen6rateur de code (Gl) et est dot6 de 
ridentifiant unique (ID-El), du jeu de paramfetres de fonctioimement (Fon- 

10 Ela) et (Fon-Elb) et du jeu de parametres de filtrage (Fil-Ela), (Fil-Elb) et 

. (Fil-Elc). L'espace (E2) est pris en charge par le gdnerateur de code (G2) et 

est dote de IMdentifiant unique (ID-E2), du jeu de parametres de 
fonctioimement (Fon-E2a) et du jeu de parametres de filtrage (Fil-B2a) et 
(Fil-E2b). L'espace (E3) est pris en charge par le generateur de code (Gl) et 

15 est dot6 de I'identifiant unique (ID-E3), du jeu de parametres de 

fonctionnement (Fon-ESa) et (Fon-E3b) et du jeu de paramfetres de filtrage 
(Fil-E3a), (Fil-E2b), (FU-E2c) et (Fil-E2d). 

- toute dependance d'un element d'application pris en charge par (E2) envers 
un element d' application pris en charge par (El) est prise en charge par 

20 Tadaptateur client (Acl) et I'adaptateur serveur (Asl). Toute d6pendance 

d*un element d'application pris en charge par (El) envers un element 
d'application pris en charge par (E2) est prise en charge par Tadaptateur 
client (Ac2) et par Tadaptateur serveur (As2). Toute dependance d*un 
element d*application pris en charge par (E2) envers un element d'application 
25 pris en charge par (E3) est prise en charge par Tadaptateur client (Ac3) et par 

I'adaptatetu: serveur (As3) , 
La figure 3 presCTite un exemple de fragment d*architecture technique reeUe 
pouvant servir k realiser une application intranet HTML / JSP. 

.30 . lA) Analvseur de description d'architecture , 

L'analyseur de description d*architecture traite des fichiers de description 
d' architecture technique exprimes dans le format defini au point 1 .3. 

n verifie que les fichiers qu'on lui transmet sont conformes k ce format, et k 
defaut il emet une erreur. 
35 II identifie, sans perte d'informations necessaires k la realisation de 

r application, les elements, enum6res ci-dessous, k partir de ces fichiers puis les en 
extraire, Ces elements constituent alors une representation decomposee de la 
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description de rarchitecture destinSe k 8tre transmise a d'autres modules. Les 
616inents en question sont : . 

- la liste des espaces technologiques (identifiant unique, gen^rateur de code et 
jeux de param^tres). 

5 - la liste des couples d' espaces technologiques clirat et serveur, et de leurs 

coiiples d'adaptateur client et serveur associ^s. 
La decomposition de la description de rarchitecture issue de T extraction de ces 
616ments est exprimee dans un format interne au g6nerateur de code architectural. Ce 
foimat est partag6 par tons les modules qui en ont besoin. 
10 L*analyseur de description d' architecture v6rifie que rarchitecture d6crite est 

coh6rente avec les capacitds des divers g6nerateurs de code et adaptateurs clients et 
serveurs qui y sont mentionn6s : 

- il verifie que le jeu de parametres de filtrage de chaque espace technologique 
est compatible avec le jeu de parametres de filtrage des generateurs de code associes^ 

15 en se reposant pour cette verification sur les services rendus par le filtre d' espaces 
technologiques (tels que decrits au point 1.5) ; 

- il verifie que les adaptateurs client et serveur mentiomi6s sont bien 
compatibles avec la technologie prise en charge par le g6n6rateur de code de 
Tespace technologique auquel ils sont eux-m&mes associ6s ; 

20 - il v6rifie aussi que les adaptateurs client et servexir sont compatibles entre 

eux ; 

- il pent aussi verifier, si les g6n6rateurs de code sont param6trables, que le jeu 
de parametres de fonctionnement de chaque espace technologique de 
rarchitecture correspond a des parametres r6f6renc6s du g6n6rateur de code en 

25 question, 

n verifie axissique pour un couple de dexix espaces technologiques doim6s 
client et serveur^ il n'y a qu'un seul couple d'adaptateur client et serveur associe.dans 
la description de rarchitecture. Ces verifications sont effectu6es afin d*eviter les 
ambiguit^s de repartition des d6pendances entre classes sur les adaptateurs. 

30 

L5) Filtre d^'espaces technologiques 

Ce module utilise un jeu de parametres de filtrage comme la definition d*un 
ensemble de classes. Pour un jeu de parametres de filtrage doxme, il determine^ pour 
toute classe, si elle appartient ou non k rensemble de classe dSfini par ce jeu de 
35 parametres de filtrage. Bnfin, il foumit deux services fond6s sur les jeux de 
parametres de filtrage : 

-le filtrage des espaces technologiques ; 

- la verification de r inclusion de deux jeux de parametres de filtrage. 
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Le filtrage des espaces technologiques consiste, k partir d'une liste d'espace 
technologique et d'une classe, k renvoyer la liste des espaces technologiques pour 
lesquels la classe en question q;)partient k Tensemble de classe dSfini par le jeu de 
param^tres de filtrage associ^s k ces espaces technologiques. 
S La notion d'inclusion de deux jeux de param&tres est d6finie comme suit : 

soient deux jexix de paramfetres de filtrages Jl et J2, Jl est inclus dans J2, si, pour 
toute classe C appartenant k Tensemble defini par Jl, C appartient k Tensemble 
d6fini par J2. 

10 1.6^ Gfaierateurs de code 

, „ . Lps generateurs de code sont des modules du generateur de. cade architectural 
capables de produire du code pour une technologie particuliere qui permet de decrire 
des algorithmes. 

Leur rdle est de produire le code correspondant a une classe k partir de la 
15 d6finition de celle-ci, de ses d^^dances avec d'autres classes. Dans le cas de 
d6pendances extemes d'une classe avec d'autres classes prises en charge dans le 
meme espace technologique, le code correspondant aux interfaces de cette classe 
avec ces autres classes est g6n6r6 par ces m3mes generateurs de code. Dans le cas de 
d6pendances extemes de cette classe avec d'autres classes prises en charge dans des 
20 espaces technologiques differents, le code des interfaces de cette classe avec ces 
autres classes n'est pas genere, mais les generateurs de code font figurer dans le code 
de cette classe une marque qu'ils choisissent, dite marque de localisation, permettant 
de retrouver Tendroit precis du code oil cette dependence sera trait^e. 

Si la technologie qu'ils prennent en charge le necessite, les generateurs de 
25 codeproduisent les fichiers necessaires pour contenir le code produit. Dans tons les 
cas, ils renvoient des references d'acces permettant d'acceder au code produit. 

Les generateurs de code sont munis d'un identifiant unique qui permet de les 
designer de fagon absolue dans la description de T architecture technique. 

Us sont pr6vus pour foumir un jeu de paramfetres de filtrage qui definit 
..30 J' ensemble.de classes (au sens,du point-1 .5) dont ils peuvent produire le code. 

lis presentent aussi optioimellement une liste de param^tres et les moyens de 
definir la valeur de ces parametres afin de qualifier Tenvironnement materiel et 
logiciel dans lequel cette technologie est executee et de definir ainsi plus finement si 
necessaire Tespace technologique et les conditions de la generation de code. 
35 Un parametre de fonctionnement pent par exemple 8tre le r6pertoh:e dans 

lequel seront stocke les fichiers source gen6r6. Un autre exemple pent 8tre le choix 
de la version du 'jdk' k utiliser dans le cas de Tutilisation d'un generateur de code 
Java. 



R>Bi«vetAl9200Vl9299EPSERB<Ioc- 



30/07/02- 18-05 



• .3 • 



1 .7^ Adaptateurs serveurs 

Les adaptateurs serveurs permettrat de g^6rer du code dans un ou plusieurs 
espaces tectmologiques donnes. Ce code peut §tre int6gre au code produit par un 
5 g6n6rateur de code. Ce code joue le r61e d'interface serveur assurant la 
conununication entre deux classes impUqu^es dans une dependance. Ce code 
s*int6gre au code qu*a produit un gen6rateur de code pour la classe serveur unpliqu6e 
dans cette dependance. Le code produit par cet adaptateur serveur permettra au code 
produit par un adaptateur client, integre au code qu'a produit un gen^rateur de code 
10 pour la classe client de cette dfependance, de s'interfacer avec lui. 

Les adaptateurs serveurs sont munis d'un identifiant unique qui permet de les 
designer dans la description de T architecture technique. 

lis indiquent dans quelle cat6gorie d'interface lis se classent Ces categories 
d'interfaces servent k determiner la compatibilit6 de ces adaptateurs serveurs avec 
15 des adaptateurs clients. EUes sont d6finies librement par les adaptateurs serveurs et 
peuvent &tre partag6es par plusieurs ad^tateurs serveurs diff6rents. 

Panni les categories d*interface que peuvent d6finir les adaptateurs, on peut 
citer par exemple CORB A® et RMI ®. 

Les adaptateurs serveurs indiquent quels sont le ou les gen6rateurs de code 
20 dont ils sont capables de modifier le code produit pour y insurer le code de leurs 
interfaces serveurs ou de produire du code d*interfa9age exteme au code produit par 
ce ou ces g6n6rateurs de code. 

Les adaptateurs serveurs produisent le code d'interface serveur a pairtir d*une 
dependance, des classes impliqu^es dans cette dependance et des references d'acces 
25 au code produit pour ces classes par les generateurs de code correspondants a cette 
dependance. 

Les adaptateurs serveur recoiventde preference un signal de fin de transmission 
de requSte de generation de code, leur indiquant qu'ils n'ra recevront plus d'autres 
ulterieurement au cours du processus de generation de code architectural. En efifet, 

30 certaines technologies peuvent necessiter que les adaptateurs attendent d' avoir re9u 
toutes les requ&tes avant de commencer h modifier le code produit par les 
generateurs. II se peut par exemple que les instructions produites doivent Stre 
agencees dans un ordre difiTerent que celui-ci dans lequel elles se trouvaient dans la 
description d'application d'origine et que cet ordre depende de la nature de toutes les 

35 instructions concemees. 

Les adaptateurs serveurs sont prevus pour pouvoir recevoir successivement 
plusieurs requetes de generation de code d'interface serveur pour plusieurs 
dependances, et ils choisissent, selon les contraintes des technologies qu'ils font 
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commiuiiquer et la manicte dont. ils les font commimiquer, s'ils produisent et 
insSrentle code des interfaces g6n6r6es au fur et d mesnre de la reception de ces 
requStes ou s'il doivent attendre le signal de fin de transmission des requStes 6mis 
par le rdpartiteur pow insurer ce code. 
5 . . 

1 .8) Adaptateurs clients 

Les adaptateurs clients permettent de g6n6rer du code dans un on plusieurs 
espaces technologiques donnes. Ce code pent etre integre au code produit par un 
g6n6rateur de code. Ce code joue le role d'interface client assurant la communication 

10 entre deux classes impliquees dans ime dependance. Ce code est de preference 
int6gre au code qu'a produit un g6nerateur pour la classe client impliquee dans cette 
d6pendance, Le code produit par cet adaptateur client s'interface avec le code, 
produit par un adaptateur serveur, integr6 au code qu*a produit un g6nerateur de code 
pour la classe serveur de cette ddpendance. 

15 Les adaptateurs clients sont munis d'un identifiant unique qui permet de les 

designer dans la description de rarchitecture technique. 

lis indiquent dans quelle cat^gorie d'interface ils se classent. Ces categories 
d'interfaces servent k determiner la compatibility de ces adaptateurs clients avec des 
adaptateurs serveurs. Biles sont definies librement par les adaptateiurs clients et 

20 peuvent etre partag6es par plusieurs adaptateurs clients difF(§rents. 

Les adaptateurs clients indiquent quels sont le ou les g6nerateurs de code dont 
ils sont capables de modifier le code produit pour y inserer le code de leurs interfaces 
clients ou de produire du code d'interfafage exteme au code produit par ce ou ces 
g6n6rateurs de code. 

25 . Les adaptateurs client doivent produire le code d'interface client a partir d*une 

dependance, des classes impliqu6es dans cette d6pendance et des references d'acces 
au code produit pour ces classes par les generateurs de code correspondants k cette 
dependance, Les adaptateurs clients doivent comprendre et utiliser les marques de 
localisation laissees par les generateurs de code avec lesquels ils sont compatibles. 

30 Les adaptateurs clients doivent pouvoir . recevoir im signal, dq- fin de 

transmission de requSte de generation de code, leur indiquant qu'ils n*en recevront 
plus d*autres ulterieurement an cours du processus de generation de code 
architectural. En effet, certaines technologies peuvent necessiter que les adaptateurs 
attendent d*avoir re9u toutes les requStes avant de conunencer a modifier le code 

35 produit par les g6nerateurs. 

Les adaptateurs clients doivent pouvoir recevoir successivement plusieurs 
requStes de generation de code d'interface client pour plusieurs dependances, et ils 
choisissent, selon les contraintes des technologies qu'ils font communiquer et la 
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manidre dont ils les font communiquer, s*il doiveat produire et ir^erer le code des 
interfaces g6n6r6es au fur et a mesure de la reception de ces requStes ou s'il doivent 
attendre le signal de j5n de trai^mission des requ8tes 6mis par le r^partiteur pour 
insurer ce code. 

5 En fin de gen6ration de code, les adstptateurs doivent avoir fait dispara!tre du 

code les marques de localisation que les generateurs de code y ont plac6. 

1.9) Comparateur 

Le comparateur v6rifie la coh6rence entre les capacit6s de g6neration de code 
10 offerte par la description d* architecture et les besoins de la description d'q^plication 
en terme de generation de code, n verifie done que les toutes les classes et 
d6pendances entre classes de T application sont prises en charge par des espaces 
technologiques et adaptateurs ad^quats. Pour ce faire, le comparateur utilise 
notajnoment les services du filtre d'espaces technologiques. II pennet de verifier les 
15 conditions suivantes : 

- pour chacune des classes que Tanalyseiu: de description d* application a 
d6cel6es dans la description d' application, il v6rifie qu'il existe, dans la 
description de rarchitecture technique, im espace technologique prenant en 
charge ces classes ; 

20 - pour chaque d6pendance, d^finie dans T application decrite, entre ime classe 

client et une classe serveur prises en charges par des espaces technologiques 
differents, il v6rifie qu'il existe un adaptateur serveur et un adaptateur client 
associes a chaque couple constitue d'un espace technologique prenant en 
charge la classe client et d'un espace technologique prenant en charge la classe 

25 serveur. 

En cas de lacunes dans la description de T architecture technique par rapport 
aux besoins de Tapplication qui rotrafne une incapacit6 de gen6rer son code, le 
comparateur 6met un message d'erreur en communiquant ces lacunes. 

30 1.10^R6partiteur 

Le repartiteur est charge de distribuer les classes et les dSpendances de la 
representation d6composee de la description de Tapplication, en fonction de 
rarchitecture. sur les difiKrents g6n6rateurs de codes et adaptateurs clients et 
adaptateurs serveurs, ainsi que le prevoit le processus ddcrit au point 1.12). 

35 Si Tordre d'appel des diff6rents adaptateurs client n'est pas indifKrent pour la 

generation de code, il determine cet ordre et appele ensuite les adaptateurs chents 
concemes dans cet ordre. Si Tordre d'appel des differents adaptateurs serveur n'est 
pas indifferent pour la generation de code, il deteraiine cet ordre et appele ensuite les 
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adaptateu^ serveiir concem6s dans cet ordre. Si Tordre d'appel des differeats 
g6n6rateurs n'est pas indiffSrent pour la g6n^tion de code, il determine cet ordre et 
appele ensuite les g^erateurs concern^ dans cet ordre. 

5 1 . 1 1 ) Coordinateur 

Le coordinateur enchaine les appels des differents 616ments du g6n6rateur de 
code architectural d6crits ci-dessus. n suit le processus d6crit au point 1.12) et il 
assure la transmission des paramtoes n6cessaires au fonctionnement du gen6rateur 
de code architectural d'un module a Tautre. Enfin, il assure Tinteraction entre le 
10 g6nerateur de code architectural et le systeme exterieur (programme appelant ou 
.^.utilisateur humain). qui ea d6clenche le fonctioiinement, en .lui transmettant les 
erreurs et les messages 6ventuellement emis par les diff6rents modules. 

1,12'> Fonctiojonement 

15 Nous aliens d6crire le fonctionnement du g6n6rateur de code architectural en .« 

relation avec la figure 4 qui illustre les 6tapes du fonctionnement. 

Btape Init Le syst6me ext6rieur declenche la generation de code archxtecturale 
par Tintetmediaire du coordinateur. II lui transmet la liste des jSchiers de description 
de Tapplicadon au format d6crit au point 1.1) et des fichiers de description de 
.20 rarchitecture au format d6crit au point 1.3). Si on foumit plusieurs fichiers, on les 
foumit simultanement dans le cas ot leur presence k tous est necessaire pour 
interpreter la description. 

Etape 1 . Le coordinateur foumit i I'analyseur de description d*application les 
fichiers de description de Tapplication exprim^s dans le format du point 1.1). 
25 L'analyseur de description d*application analyse ces j&chiers et renvoie la 
representation ddcomposee de Tapplication. En cas d'erreur emise lors de cette 6tape, 
le processus de generation s'arrSte. 

Etape 2, Le coordinateur foumit k Tanalyseur de description d' architecture les 
• fichiers de description de Tarchitecture exprimes dans le format du point 1.3). 
- 30, .. .L'analyseur - de.. description .d'architecture , analyse ces fichiers -et renvoie la 
rqjresentation decomposee de rarchitecture. Au cours de cette 6tape Tanalyseur de 
description d'architecture efifectue les taches suivantes 

Btape 2.1. Si les generateurs de code sont parametrables, Tanalyseur de 
description d' architecture soUicite le g6n6rateur de code de chaque 
35 espace technologique pour obtenir sa liste de parametres de 

fonctionnement. L*analyseur de description d'architecture verifie alors 
que le jeu de parametres de fonctioimement de ces espaces 
technologiques ne definit de valeur que pour des parametres de cette 
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liste. Dans tons les cas, il sollicite le generaleur de code de ohaque 
espace technologique pour en obtenir son jeu de param^tre de filtrage. 
Eta pe 2^ > Pour chaque espace technologique, I'analyseur de description 
d^architecture interroge le filtre d'espaces technologiques et invoque le 
service de v6rification de Tinclusion de deux jeux de paramdtres de 
filtrage, afin de verifier que le jeu de parametres de filtrage de T espace 
technologique est bien inclus dans le jeu de param&tres de filtrage du 
g6n^:ateur. Une erreur est 6mise dans le cas contraire. 
Etape 2.3. Pour chaque adaptateur serveur utilise dans T architecture, 
Tanalyseur de description d'architecture interroge cet adaptateur afin 
qu'il lui renvoie la liste des gen6ratevirs de code avec lesquels il est 
compatible, ainsi que la cat6gorie dans laquelle il classe les interfaces 
qu'il g6nfere. L'analyseur de description d'architecture v6rifie alors que 
pour chaque espace technologique dont Tadaptateur serveur doit 
realiser les interfaces serveiir, le gen6rateur de code associ6 k cet espace 
est bien present dans la liste de g6n6rateurs de code avec lesquels il est 
compatible. Une erreur est Smise dans le cas contraire. 
Etape 2.4 . Pour chaque adaptateur client utilis6 dans 1* architecture, 
Tanalyseur de description d'architecture interroge cet adaptateur afin 
qu'il lui renvoie la liste des g6n6rateurs de code avec lesquels ii est 
compatible ainsi que la cat6gorie dans laquelle il classe les interfaces 
qu'il g6n6re. L'anedyseur de description d'architecture verifie alors que 
pour chaque espace technologique dont T adaptateur client doit realiser 
les interfaces client, le generateur de code associe a cet espace est bien 
present dans la liste de g6nerateurs de code avec lesquels il est 
compatible. II verifie aussi que T adaptateur client en question produit 
bien des interfaces de la meme cat6gorie que T adaptateur servexu: 
auquel il est associ6. Une erreur est 6mise dans le cas contraire. 
En cas d*erreur, le processus de generation s'arrSte. 

Etape 3. Le coordinateur transmet la representation d6compos6e de 
appKcation et la representation decompos6e de T architecture au comparateur. Le 
omparateur v6rifie que les besoins de I'application en tenne de generation de code 
ont pris en charge par Tarchitecture : 

Etape 3.1. Pour chaque classe definie dans Tapplication, le comparateur 
interroge le filtre d'espaces technologiques et invoque le service de 
filtrage d'espaces technologiques, afin d*obtenir la liste des espaces 
technologiques de 1' architecture qui preiment en charge cette classe. Le 



R\BrevetA1920QM9299GP SERE doe • tftOS 



MV07/02 . 18:05 




comparateur v6rijae alors que pour chaque classe, cette liste est non 
vide. Dans le cas contraire^ una erreur est emise, 
Le comparateur poursuit ensuite la detection des lacunes eventuelles en 
v6rifiant que pour chaque d^p^dance entre deux classes, Tarchitecture definit un 
5 couple d'ads^tateurs client et serveur pour chaque paire d'espaces technologique qui 
prend.en charge les deux classes de cette dependance. 

Si la comparaison se solde.par une erreur, la liste des lacunes d6tect6es est 
. transmise k Tappelant et le processus de g6n6ration s'arrete. 

Etape 4. Le coordinateur transmet au repartiteur la representation decomposee 
10 , de Tapplication, la repr6sentation decomposee de T architecture. Au cours de cette 
6tape, le r6partiteur efiectue les taches suivantes : 

Etape 4.1. Pour chaque classe definie dans T application, le r6partiteur 
interroge le filtre d'espaces technologiques et invoque le service de 
filtrage d'espaces technologiques, afin d'obtenir la liste des espaces 
15 , technologiques de Tarchitecture qui prennent en charge cette classe. 

Etape 4.2 . Pour chaque classe et pour chaque espace technologique 
prenant en charge cette classe, le r6partiteur regroupe cette classe, ses 
dependances, en lui indiquant celles qui correspondent k des 
d6pendance envers des classes prises en charge par des espaces 
20 technologiques differents de Tespace considere, et les transmet au 

gen6rateur de code associe k cet espace. Le repartiteur lui transmet aussi 
le jeux de paramdtres de fonctionnement qualifiant renviroimement 
materiel et logiciel definis par cet espace technologique. 
En retour, le r6partiteur obtient les r6ferences d'accds aux codes sources 
25 produits. 

Etape 4.3, Le r6partiteur traite chaque d6pendance de la repr6sentation 
d6compos6e de la description d' application concemant deux classes 
prises en charge par des espaces technologiques difG§rents. 
Pour chacune de ces d6pendances, le repartiteur determine alors quels 

30., _ adaptateurs. s.eryeur dqivQat ,.pr^ndre en .cliarge., cette d6p.endance, 

d'apres la description d'architecture. Pour une d6pendance CTitre une 
classe cUent et une classe serveur, les adaptateurs serveur en question, 
sont ceux qui sont associes a tine dependance entre les espaces 
technologiques qui ont pris em charge la classe serveur et les espaces 
35 technologiques qui ont pris en charge la classe client. 

Pour chacune de ces dependances, le repartiteur transmet alors cette 
d6pendance, ainsi que les classes concemees par cette dependance et les 
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r6f6rences d'acces aux codes sources associ6s k ces classes, k ces 
ad^tateurs serveur. . 

Etape 4.4. Le r6partiteur traite chaque d6pendance de la reprSsentation 
d6compos6e de la description d's^plication concemant deux classes 

5 prises en charge par des e^aces technologiques difTSrents. 

Pour chacune de ces d^endances» le r^partiteur d6tennine alors quels 
adaptateurs client doivent prendre en charge cette dSpendance, d'aprds 
la description d*architecture. Pour une d6pendance entre une classe 
client et une classe serveur, les adaptateurs client en question sont ceux 

10 qm sont associes k une dependauce entre les espaces technologiques qui 

ont pris en charge la classe serveur et les espaces technologiques qui 
ont pris en charge la classe client. 

Pour chacune de ces dependances, le r6partiteur transmet alors . cette 
dependance, ainsi que les classes concem6es par cette dSpendance etles 
15 references d'acc6s aux codes sources associes k ces classes, k ces 

adaptateurs client. 

Etape 4,5. Le r6partiteur appelle chaque adaptateur serveur qui a 6t6 
sollicit6 durant i'etape 4.3 et lui envoie le signal de fin de transmission 
de requ&te. Cet appel se fait dans I'ordre requis si c'est nScessaire, ainsi 

20 que le determine le r6partiteur. 

Etape 4.6. Le r6partiteur appelle chaque adaptateur client qui: a ete 
solhcite durant T etape 4.4 et lui envoie le signal de fin de transmission 
de requgte. Cet appel se fait dans Tordre requis si c'est nfecessaire, ainsi 
que le determine le rfepartiteur. 

25 En cas d'erreur, le processus de generation s'arrete. 



2) Le language de description de logiciel 

2A) Oualification du language selon rinvention. 

30 L'invention s^intfegre k un langage de description de logiciel. Elle Ivu permet de 

decrire un logiciel, existant ou en cours d^eiahoration, sans que cette description ne 
contieime d'informations liees k la realisation pratique et technologique de ce logiciel 
(c'est-^-dire sans d6pendance envers les capacites specifiques d'un langage de 
programmation, d'une plate-forme informatique materielle ou logicielle, ou plus 

35 gen6ralement d'une technologie particuliere) mais en decrivant de fa9on concrete son 
fonctiormement. La description concrete du fonctionnement est realisee gr3.ce k la 
mise k disposition via le langage de notions concretes liees a la mise en oeuvre 
informatique pratique des applications. Ces notions sont destinees k servir de base a 
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la description de Tapplication. L' exploitation de ces notions et la clarification de lear 
fonctionnement et de leur role peuvent reposer sur lenr association k une 
specification fonctionnelle et technique exprimd dans un langage, qui peut meme Stre 
un langage naturel tel que le firanpais, qui ne presume par des technologies 
5 employees pour la mettre en oeuvre. Citons en exemple des notions telles que celles 
de composant graphique, d*6v6nement de p6riph6rique, de verification de donn6e k 
partir d'une saisie dans Tinterface homxne machine, de navigation, de stockage 
d'information, de requSte de recherche d'information dans une structure de stockage 
d'information, etc. 

10 L'absence, dans les descriptions faites a Taide d*un langage dot6 de 

rinvention, d'informations li6es a la mise en oeuvre pratique et technique de 
Tapplication dScrite place ce langage, dans le diagramme de classement des langages 
de la figure 1, au dessus des langages de moddlisation abstraite. En effet, son niveau 
d'independance technologique est sup6rieiu: puisqu'il ne souffire pas de leurs 
15 limitations dterites dans la partie consacr6e k Tart ant6rieur. 

En ce qui conceme r^chelle horizontale du diagraname de la figure 1, le 
langage selon rinvention se place k droite des langages de quatri^me generation. En 
efFet, si, tout comme eux, T analyse semantique automatique peut se reposer sur 
Tassurance de Tutilisation, par le progranoutneur, d*un cadre strict lors de la 
20 modeUsation d'un service technique ou fonctionnel donne, la richesse des elements 
disponibles pour decrire une application informatique est sup6rieure car elle est 
rendue independante d'une implementation specifique et se concentre sur la 
description du service rendu. 

2.2) Structure du language selon rinvention 
2.2.nContexte 

L'invention repose sur im langage de description de logiciel, c'est-i-dire qu'il 
permet de realiser ime representation de tout ou partie d'une application logicielle. 
Le langage considere permet de d6finir des classes dites classes standards. 

- Ce langage .peut definir des operations eiementaires permettant de decrire des 

algorithmes. 

Ce langage supporte eventuellement Theritage, c'est-^-dire la capacite de 
definir des classes enrichissant d'autres classes. En cas de prise en charge de 
rheritage, le langage permet eventuellement de definir des classes abstraites, c'est-^i- 
dire des classes qu'on ne peut instancier en objets et dont cortaines m6thodes peuvent 
6tre abstraites, c'est-a-dire des methbdes dont le fonctionnement est non defini mais 
devra etre defini par les classes non abstraites qui heritent de ces classes abstraites. 
Le langage permet eventuellement de d6finir la portee des attributs, des methodes et 
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des classes, c'est-^-dire la capacite d'acces des autres classes a ces difif6rents 
616ments selon leur position relative. Ce langage supporte 6ventuellement le 
polymorphisme, c'est-i-dire la capacite de manipuler une instance d'une classe B 
h6ritant d'une classe A comme si elle etait une instance de la classe A et, lore 

5 d'appels a des m6thodes de cette instance manipxilee comme une instance d'une 
classe A, d*utiliser T implementation d6finie dans la classe B au lieu de 
rimplementation d6finie dans la classe A. Le lexique et la syntaxe de ce langage sont 
indiff6rents, du moment qu'ils respectent les contraintes etablies au paragraphe 
pr6cedent. Ce langage pent 6ventuellement d6finir des types primitifs (par exemple, 

10 les booleens ou les entiers) qui ne sont pas necessairement des classes, et dans ce cas, 
eventuellement definir des op6rations el6mentaires permettant de manipixler ces types 
primitifs. 

Le langage est d6fini par une specification qui precise Tensemble de ces 
616ments et leurs conditions d'utilisation (lexique et syntaxe, et le cas 6ch6ant, 
15 heritage, polymorphisme, classes abstraites, port6e, types primitifs, op6rations 
el6mentaires). 

Enfin, le langage, tel qu'il est d6fini jusque Ik, ne foumit pas et ne doit pas . 
foumir de moyen d'acces k des services techniques ou fonctionnels pouvant etre • 
rendus par une quelconque plate-forme mat^rielle et logicielle susceptible 

20 d*accueillir un logiciel mod61ise k Taide de ce langage, hormis les operations 
el6mentaires sus-citees. En exemple de ces services auquel le langage ne doit pas . 
donner acces a ce stade, citons : la capacity d'afficher des informations sur un . 
periph6rique d*affichage ou d'impression, la reception d'evenements emis par un 
p6riph6rique de commande comme le clavier ou la souris, la communication avec un 

25 service de stockage d'information, ... 



2.2,2^ L'invention 
L'invention consiste : 

- k enrichir le lexique et la syntaxe du langage de fa?on a le doter d'un format 
30 de description sp6cifique pour des classes dites classes fondamentales, 

- et associer optionnellement k ce langage une technique de definition de ces 
classes fondamentales. 

Ces classes sont dites fondamentales, car elles donnent, aux autres classes qui 
les utilisent, un accds k des services techniques ou fonctionnels fondamentaux, c'est- 
35 i-dire des services qui ne sont pas port6s directement par ces classes fondamentales 
via une ddfinition exprim6e gi^ce au langage lui-mSme. Contrairement aux classes 
standards, le lien entire les classes fondamentales et leur definition est exteme au 
langage. II depend totalement d*ime interpretation exterieure, par exemple par les 
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outils utilisant cette invention^ fond6e sur une d6fimtion exterieure aux classes 
fondamentales. 

Le format de description des classes fondamentales^ intSgre au langage, 
pemaet : 

1- de toujours pouvoir identifier une classe fondamentale conune telle, 

2- de toujours pouvoir distinguer ime classe fondamentale d'une classe 
standard, 

3- de definir son identifiant unique, 

4- de d6finir ses attributs, qui ne peuvent avoir ime port6e les rendant invisible 
k toute autre classe si le langage pr6voit la definition de la port6e, 

5- de d6finir des methodes dites fondanoientales sans en d6tailler le 
fonctionnCTaent, qui sont par nature non abstraites, dans le cas oil les classes 
abstraites sont Si^port6es, et qui ne peuvent avoir une port6e les rendant 
invisibles i toute autre classe si le langage pr6voit la definition de la portee. 
Ces m6tihiodes fondamentales. sont des methodes dont la definition se limite 
aux seules signatures, mais dont le fonctionnement n'est pas exprim6 grSce 
au langage lui-meme et doit pourtant 6tre consid6r6 comme ddfini par tout 
systeme exploitant ce langage. 

La technique de definition des classes fondamentales impose, pour une classe 
fondamentale, de foumir : 

1- sa description grSce au langage tel qu'enrichi ci-dessus par le format de 
description des classes fondamentales, 

2- si rh6ritage est support6 et dans ce cas de fa9on optionnelle, un lexique et 
une syntaxe, compatible avec le langage, sp6cifiques a cette classe, 
d6finissant le format utilis6 dans le langage pour d6crire les classes heritant 
de cette classe, 

3- si rinvention le pr6voit, la specification fonctionnelle ou technique 
exhaustive des services rendus par cette classe, exprim6e dans un langage 
ind6pendant des technologies de mise en CBUvre, qui pent m§me 6tre xax 
langage naturel tel que le fr.an9ais* Cette specification ne doit pas presumer 
des technologies employees pour la mettre en oeuvre. EUe doit clarifier le 
fonctionnement de toutes les mettiodes fondamentales de cette classe (cf le 
dernier tiret au point ci-dessus consacre au format de description des classes 
fondamentales). II s^agit en resume de la s6mantique complete des points 1 
et 2 de cette technique. Cette specification sera eventuellement traduite dans 
les langues des personnes susceptibles de realiser des outils prenant en 
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charge cette classe, avec, poiur clique version^ la r6f6reiice de la langue en 
se basant pour cela sur un syst^e d'identification de langue defini. 

Le fonctioimement de ces classes fondamentales n'est done pas defini 
explicitement, de maniere algorithmique, en utilisant le langage Ini-mSme, mais peut 
Stre defini seulement par cette specification fonctionnelle ou technique exprimee 
dans un langage independant des technologies de mise en oeuvre, tel qu'un langage 
naturel comme le firan9ais par exemple. 

De plus, du fait de T absence exposee au point 2.2 A) de moyen d'accds a des 
services techniques ou fonctionnels pouvant etre foumis par xme quelconque plate- 
forme materielle ou logicielle, seules les classes fondamentales sont susceptibles de 
donner acc^ a ces services. 

Les classes fondamentales sont elles-m@mes soumises aux lois de rh6ritage si 
celui-*ci est present dans le langage. Dans ce cas, on peut faire h6riter une classe 
fondamentale d'une classe standard ou fondamentale, au m8me titre qu'on peut faire 
heriter une classe standard d'une classe standard ou fondamentale. 

23'i Fonctionnement 

Fonctionnement des classes fondamentales. La mise en oeuvre des 
specifications des classes, fondamentales est done enti&rement devolue aux outils qui 
exploitent un langage selon Tinvention. Ce sont ces outils qui r6alisent ou simulent le 
fonctionnement de ces classes, selon les besoins. 

Resvonsabilite du fonctionnement des classes fondamentales , Les outils qui 
utilisent ou permettent d^effectuer une description d'application avec vox langage 
selon rinvention et d6pendant de classes fondamentales, doivent ainsi etre con9us de 
fa9on k prendre en compte les specifications de ces classes fondamentales lorsqu'ils 
doivent les interpreter. L'interpretation du r61e de ces classes fondamentales par ces 
outils repose done sur la conformite de ces outils avec les specifications de ces 
classes fondamentales. 

Integration eventuelle de classes fondamentales a un lansasre . Un langage 
selon rinvention peut 6ventuellement int6grer, dans sa specification elle-meme, un 
ensemble de ces classes fondamentales (dans ce cas non modifiables par Tutilisateur 
du langage) qui, une fois sp6cifi6es selon la technique d6crite au point 2.2.2, 
permettent aux descriptions de logiciels effectu^es grice k ce langage et exploitant 
ces classes fondamentales de faire reposer ces logiciels sur les services de ces classes 
fondamentales. 

Extension dun langasre par des classes fondamentales tors de son utilisation . 
La technique de definition des classes fondamentales peut aussi Stre rendue 
accessible aux utilisateurs du langage pour 6tendre les capacites du langage au-dela 
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de ses specifications en y ajoutant de nouvelles classes fcndamentales en plus des 
classes fondamentales 6ventuellement fournies avec le langage. Dans ce cas, il sera 
preferable de doter les outils exploitant ce langage d'un mecanisme d*extension qui 
permette aux utilisateurs d6finissant ces nouvelles classes fondamentales d'enrichir 
5 le fonctionnement de ces outils a Taide de modules additioimels afin que ces outils 
puissent prendre en compte dans le cadre de leur fonctionnem^t ces classes 
.fondamentales confonn6ment h la specification de ces classes. 

Interet pour I'analvse semantiaue automattque . Les outils qui pemiettront 
d*analyser les descriptions effectu6es grice k un langage dot6 de cette invention 

10 seront capables d*identifier des services techniques ou fonctionnels par la simple 
identification de rutilisation des classes fondamentales dans la description 
d' application. Cette analyse sera ainsi faite sans ambiguite. En effet, la capacity d'un 
outil d'analyse a foumir une. analyse s6mantique automatique de ces descriptions 
repose seulem^t sur la. connaissance, par le developpeur de cet outil» des 

15 specifications des classes fondamentales, et non sur la deduction du role des classes 
utilisees par Tanalyse algorithmique de la definition des classes decrites k I'aide du 
langage, chose impossible.aujourd'hui sans intervention humaine. 

Notion de difinition exclusive et methode de renforcement Dans le cadre d*un 
langage selon F invention, I'exclusivite, possedee par les classes fondamentales, de la 

20 foumiture d'un service materiel ou logiciel donn6 reposant sur les specificit6s de la 
plate-forme d'accueil du logiciel decrit, est assuree par Tabsence de ces services dans 
la definition du langage lui-meme. Par centre, pour les services purement 
algorithihiques» cette exclusivite n'est pas assur6e par le langage, car il permet la 
description d'algorithmes, et elle reposera done sur une contrainte exterieure. Cette 

25 exclusivite est Tassurance du deteraiinisme complet de Tanalyse semantique 
automatique. Pour Tassurer, on concevra des outils produisant les descriptions de 
logiciels decrits grace a un langage dote de cette invention, de telle manidre qu'il soit 
impossible d'utiliser le langage pour decrire des algorithmes dans certains cas pris en 
charge par des classes fondamentales donnant acces a des services algorithmiques 

30. particxiliers. • _ . 

Application h la generation de code. Parmi les applications possibles de. 
Tanalyse semantique automatique permise par Tinvention, on pent citer la generation 
de code vers des architectures techniques distribuees qui pemiet notanomient k ^m 
logiciel decrit k Taide d*un langage dote de cette hivention d'Stre portee vers 

35 n'importe quelle architecture technique foumissant les services decrits par les classes 
fondamentales utilisees dans la description de ce logiciel. En particulier, un language 
selon rinvention pent avantageusement Stre utilise avec un logiciel de generation de 
code selon I'invention tel que du type decrit au point 1) de la presente description. 
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Bien entendu, la presente invention n'est pas limitee aux examples et au mode 

5 de realisation decrits et repr6sentes, mais elle est susceptible de nombreuses variantes 
accessibles k Wiomme de Tart 

Le logiciel de generation de code ainsi quele language de description de 
logiciel selon Tinvention procurent un gain de productivite du d6veloppement des 
applications informatiques estime a prbs de 70% par Tautomatisation d'un certain 

10 nombre de t&ches de programmadon. L'invention conf&re aussi ime liberty sans 
Equivalent par report aux technologies utilis6es au cours du processus de 
dSvelbppement. Les technologies sont une cause majeure d'al6as et d'incertitudes 
dans les projets informatiques. Cette liberty se traduit done par une diminution des 
xisques d'echecs et une meilleure tenue des budgets et des d61ais.Le fait de ne deJBnir 

15 qu'im modele d'application ind6pendant des technologies of&e plusieurs avantages. 
D'abord, on n'a pas a considerer les contraintes techniques durant la mod61isation, ce 
qui simplifie celle-ci. Bnsuite cela permet d'obtenir un modele plus proche des 
attentes des utilisateurs car non perverti par des questions qui n'ont rien a voir avec 
le fonctionnel. De ce fait la phase de conception converge plus rapidement vers le 

20 resultat souhaite. De plus, il n'y a pas ensuite d'autres taches a ex6cuter que la 
realisation de ce module. En effet, on peut obtenir P application int6gralement 
realis6e techniquement sans intervention humaine autre que Tindispensable 
conception technique. Cela est possible car on peut produire le code de 
programmation automatiquement k partir du module qui contient toutes les 

25 informations necessaires pour decrire T application. 

Par ailleurs, Tinvention am61iore la fiabilit6 sur deux plans : la fiabilit6 de 
Tapplication iufoimatique obtenue et la fiabilitd des pr6visions de d6roulem^t des 
projets. Concemant les applications informatiques, ils peuvent 8tre realises 
automatiquement par le logiciel de g6n6ration de code et ils ne comportent pas 

30 d'autres erreurs que celles introduites dans la conception fonctionnelle, et celles 
introduites par les g6n6rateurs de code eux-memes. On peut raisoimablonent partir 
du principe que ces demiferes seront moins nombreuses que celles produites par un 
progranuneur humain car les sch6mas de programmation utilises peuvent 8tre rodes 
sur un nombre de projets tres important. Et elles sont susceptibles de corrections et 

35 d' ameliorations incr6mentales au cours de la vie du produit, ce qui permettra de 
capitaliser sur les progr^s en quality. Quant aux errevirs introduites par la conception 
fonctionnelle, les modules produits par appUcation de l'invention etant plus simple a 
valider, on peut estimer qu*elles seront moins nombreuses. 
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Concemant le d^roiilement des projets, il faut noter que, dans de nombreux 
projets, les aspects techniques introduisrat des di£Scult6s msoup9onn6es de 
r6alisation et que certains choix d'architecture se r6v61ent k Tusage d6sastreux pour 
la tenue des delais et des budgets. Jusqu'alors on 6tait souvent contraint de les subir, 
5 car il 6tait trop tard pour revenir sur ce type de choix. Grace a Tinvention, les 
contraintes techniques sont assum6es par les g6n6rateurs de code, et les choix 
d'architecture sont revisables. Le deroulement des projets subira done moins de 
heurts et s'ecartera moins des previsions, Enfin un autre element peut-etre encore 
plus important qui vient r6guli6rement perturber le d6roulement des projets, est le 

10 changement des sp6cij5cations fonctionnelles en cours de projet C'est im evenement 
quasi-systematique et qui a des consequences lourdes sxrr les projets en terme de 
charge. Cet inconv6nient pent etre evit6 car il n'y a plus d'impact en terme de charge 
autre que la redefinition du modele grace k I'invention, et la transcription technique 
de ces modifications a un cout quasi-nul conome nous Tavons vu. Comme les. 

15 sp6cijScations fonctionnelles sont valid6es avec les utilisateurs k partir de la 
simulation du modMe, les changCTaents devraient de surcroit etre moins jfrSquents car 
ime validation en condition r6elle est plus fiable qu'une validation sur schwas ou 
maquette. 

Un autre avantage de I'invention est la possibility de reutiliser les 
20 d6veloppements. Gette possibility issue de Tinddpendance des technologies, peimet 
de capitaliser k I'interieur d'un projet ou entre des projets ayant des Sl^ments 
fonctionnels en communs. Cela reduit notablement les cotits de developpement et 
augmente la pertinence des applications produites par la validation crois6e dont elles 
font ainsi Tobjet A long terme cette capacite de r6utilisation pent se traduire par la 
25 possibilite de r^aliser un portage de Tapplication. Cela permet de migrer une 
application vers une nouvelle architecture technique, lorsque cela s'avdre n6cessaire, 
sans surcoflt important. 
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REVENDICATIONS 

1. Un logiciel de g6ii6ration du code mformatique d*au moins une partie 
d'une application informatique, dans lequel le logiciel g6n6re ledit code informatique 

5 k partir d'une description de ladite partie de T application informatique en r6partissant 
ladite description OTtre plusieurs g6nerateurs de code en fonction de regies de. 
repartition modifiables, chaque g&i6rateiir de code traduisant la partie de ladite 
description qui lui est foumie, pour foumir au moins une partie dudit code 
informatique dans un langage respectif. 

10 

2. Le logiciel selon la revendication 1, decomposant ladite description 
sous forme de classes d'objets, le logiciel r6partissant lesdites classes d'objets entre 
les g6nerateurs de code en fonction desdites regies de repartition, chaque gen^rateur 
de code traduisant les classes d'objets qui lui sont foumies, en ladite partie 

15 correspondante dudit code informatique* 

3. Le logiciel selon la revendication 2, decomposant en outre ladite 
description sous forme de dependances entre lesdites classes d'objets, et dans le cas 
d'une d6pendance entre deux classes d'objets traduites chacune par un g6n6rateur de 

20 code difiKrent, le logiciel fait traiter ladite d6pendance par deux adaptateurs qui la : 
traduisent chacun en un code iiLformatique d'interfafage des codes informatiques 
produits par lesdits g6n6rateurs de code pour lesdites deux classes d'objet 

4. Le logiciel selon la revendication 3, dans lequel chacvin des deux 
25 adaptateurs produit ledit code informatique d'interfa9age respectif pour une classe 

d'objets respective parmi lesdites deux classes d'objets, chacun des deux adaptateurs 
inserant de pr6f6rence le code infomiatique d'interfa^age respectif dans le code 
informatique produit par I'un desdits generateurs de code pour ladite classe d'objets 
pour laquelle 1' adaptateur a produit ledit code informatique d'interfa9age. 

30 

5. Le logiciel selon la revendication 3 ou 4, dans lequel lesdits deux 
adaptateurs devant traiter la d6pendance sont choisis par le logiciel suivant des rfegles 
d'affectation associant, pour le sens de la d6pendance desdites deux classes d'objets, 
un adaptateur correspondant k chacun des g6n6rateurs de code traduisant lesdites 

35 deux classes d'objets, lesdites regies d'affectation etant modifiables. 

6. Le logiciel selon Tune quelconque des revendications 1 a 5, g6n6rant 
ledit code informatique a partir de ladite description faite dans un langage organis6 
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en classes d'objets, dans lequel ledit langage permet de d6finir d&s premieres classes 
donnant acc6s a des services techniques ou fonctionnels k foximir par les plate- 
formes informatiques mat^rielles et logicielles recevant Tapplication informatique, 
lesdits services n'etant pas d6finissables par ledit langage, et les autres classes dudit 
5 langage ne peuvent acc^er k un quelconque desdits s^ivices que par rintermediaire 
desdites premises classes. 

7. Le logiciel selon la revendication 6, repartissant ladite description 
entre les g6n6rateurs de code en fonction des regies de repartition associant au moins 
10 certaines desdites premieres classes ou desdites autres classes dudit langage a au 
moins un desdits gen6rateurs de code, et dans le cas ou la revendication 6 depend de 
la revendication 2, le logiciel decompose ladite description de preference en 
premises classes ou autres classes dudit langage. 

15 8. Le logiciel selon la revendication 6 ou 7 en ce qu'elles depmdent de 

la revendication 5, dans lequel le logiciel d6compose ladite description sous forme de 
d6pendances entre lesdites classes d'objet k partir de d6pendances entre lesdites 
premieres classes ou autres classes dudit langage. 

20 9. Un langage de description de logiciel, notamment du type langage objet de 
mod^lisation d'application infomiatique, organise en classes permettant de definir 
des premieres classes donnant acces a des services techniques ou fonctionnels a 
foumir par les plate-formes informatiques mat6rielles et logicielles recevant 
rapplication incformatique, dans lequel : 

25 - lesdits services ne peuvent pas etre d6finis par ledit langage, et 

- les autres classes ne peuvent acceder k un quelconque de ces services 
techniques ou fonctionnels que par Tinterm^diaire desdites premieres classes. 

10. Logiciel permettant de constmire graphiquement ou textuellement un 
30 modfele d'^plication infomiatique, notanament un module d'interface honune- 
machine d'application intformatique et de foumir une description du modMe dans un 
langage selon la revendication 9. 
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ABREGE 

Le logiciel genere le code infonnatique d'au moins une partie d*une 
application infonnatique, a partir d'une description de cette partie de replication 

5 infonnatique en la rdpartissant entre plusieurs generateurs de code en fonction de 
regies de repartition modifiables. Chaque g6n6rateur de code traduit la partie de la 
description qui lui est foumie, pour foumir au moins une partie du code infonnatique 
dans un langage respectif. L'invention propose aussi un langage de description de 
logiciel, notamment du type langage objet de mod61isation d'application 

10 infonnatique. L^invention propose aussi un logiciel permettant de construire 
graphiquement ou textuellement un modele d'^plication infonnatique, notamment 
un module d'interface homme-machine d'application infonnatique et de foumir une 
description du modele dans un langage de description de logiciel selon Tinvention. 
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